This invention relates generally to computer systems, and more particularly to reducing database workload volume.
Large cash and derivatives exchanges have some of the most aggressive requirements for throughput, responsiveness, and reliability. One of the key elements in an exchange is an order book. The order book holds orders prior to any form of matching between buyers and sellers at the exchange. It is important that the order book is protected against loss or corruption of data in the event of a failure. In addition, the order book must support a high volume of access, in some cases as many as tens of thousands of accesses per second. One way that the order book is protected is through storage in a database. A common problem is that performance requirements for storing the order book are such that conventional database techniques are not adequate relative to speed requirements.
In order to improve performance on the hardware side, high speed fixed hard drives available may be utilized, along with large memory caches on disk controllers, storage area networks and use of striping when available. Another approach is to use solid state disk drives in order to minimize the impact of the latency of writing to a physical medium. Both of these approaches deliver trading performance gated by hardware speed, which caps throughput at several thousand orders per second. Since one or more structured query language (SQL) statements are created for each order, throughput is constrained by the speed of a single processor to process these SQL statements. Also, these higher speed devices lead to more expensive solutions.
On the software side, performance may be improved by tuning the database and adding customized code to specifically handle the order book load. This may be done in conjunction with the hardware techniques described above to ensure that they compliment each other. Another approach is to batch up instructions as much as possible, and to maximize database throughput by committing periodically (generally after processing a specific number of orders or after a set period of time) rather than after every SQL statement. Another alternative is to use in-memory databases and to replicate the data to another active instance of the system, rather than trying to use some kind of persistent physical storage. This often results in complex systems that rely on high-speed middleware to ensure that data is replicated reliably.
While using faster hardware or batching database instructions may increase performance, these techniques do not reduce the total volume of database instructions, thus limiting performance. Therefore, what is needed is a method to reduce the number of database instructions to a minimum while maintaining the integrity of the database instruction sequence and also meeting the performance requirements.